Checks are a pervasive non-cash form of payment. For example, it is estimated that over 60% of American households use one or more checks to pay for retail purchases. Despite the significant convenience checks provide customers, accepting checks can expose merchants and other payees to the risk that a check may be fraudulent in which case the check may not be honored by the bank of first deposit or the payor's bank. The payor's bank may also not honor checks for a variety of other reasons including the fact that the account is closed or there are insufficient funds in the account. In many cases where a check is bad, the payee (and merchants in particular) find it difficult, if not impossible, to collect payment.
It is desirable to have a payment validation system that will enable merchants to reject as many bad checks as possible while also rejecting as few good checks as possible. Due to the nature of retail environment, merchants must make a quick and accurate decision whether to accept or reject a check, prior to completing a transaction. Thus, the decision should be made at the point of presentment. This decision is also necessary when sales occur over the Internet and the form of payment is a check.
Similarly, when a check is deposited at a financial institution it is desirable for the financial institution to be able to determine, at the point of presentment, if the check will be returned or the transaction can be completed without risk of loss. One of the problems with existing check clearance processes is that there is a significant delay between the time a check is first deposited at the presenting bank and the time the payor's bank accepts or rejects the check. Typically, the presenting bank either places a hold on the depositor's bank account until the presenting bank receives confirmation of payment transfer (from the payor bank) or the presenting bank pays out the money to the depositor (presenter) and assumes the risk that the check will be rejected by the payor bank as an unpaid check.
Either way, checks are sent to the payor bank, either physically, or as part of a check truncation process in which payment data is processed, or as part of an electronic check presentment (ECP). Upon presentment, the payor bank processes the checks to debit the affected payor's account. During this process conditions such as insufficient funds, closed accounts, uncollected balances, stop payment orders and other irregularities may occur that will not allow the check to be debited to the payor's account. Each such exception typically requires review by a bank officer to determine whether the check should be paid or whether the check should be returned to the presenting bank that submitted the check for payment. If the check is returned, it is physically (or in the case of ECP, electronically) sent back to the presenting bank and a decision is made by an officer thereof to either re-present the check to the payor bank by reinitiating the entire clearing process in the hope that sufficient funds are then available to pay the check or to notify the depositor that the check was unpaid and is to be returned to the depositor, with the depositor's account being debited for the unpaid check as a charge back. This decision process is typically a manual process that requires the bank officer to examine the check and, in the majority of cases, to review prior instructions provided by the depositor to determine the appropriate disposition of the returned check.
It is further possible that during this process, the presenting bank will be out-of-pocket for the amount of the deposited check, if it elected to pay out cash for the check. More elaborate fraud schemes are check kiting, which take advantage of this situation.
One significant problem in assessing the risk of accepting a payment made by check, either by a merchant, at a bank teller line or through an ATM machine is the availability of relevant information, in real time, accurately. The procedures and processes for clearing checks generally differ from one bank to another because not all banks clear their checks directly. Some may outsource their check clearing and reconciliation function to outside service providers. In addition, there is a three hour time difference between East coast banks and West coast banks, which creates a gap in updating and/or obtaining accurate transaction status, account balances, etc.
Accordingly, there is a need for real time, on-demand, check validation that can be broadly applied by a wide variety of participants including merchants, banks, and other financial institutions which process checks in batch.
The prior art has attempted to deal with these problems, albeit in a non-comprehensive manner. For example, U.S. Pat. No. 6,189,785 to Lowery discloses a demand deposit account data processing system that allows merchants to settle transactions on line and in real time and that automatically processes transactions in a number of exception conditions. The system comprises demand deposit account data that originate from a data source (such as a payor bank). The system requires at least one point of sale terminal that is specially adapted to receive that data in order to initiate a transaction. A central computer system interconnects the data source and the point of sale terminal. The data source provides some validation capability based on the availability of one or more databases, including a positive database, a negative database, a velocity/risk database, a closed account database, and an exception database. The central computer system communicates with the data source to settle the transaction on line or through conventional automated clearinghouse channels. The system also preferably automatically updates all of its databases with pertinent transaction information once a transaction result is obtained.
The Lowery system has some significant limitations. For example, it requires and depends on an integrated point of sale terminal, with data storage and specific, dedicated algorithms designed only for physical merchants. The system thus cannot handle other types of entities or institutions that may wish to validate a check or debit payment. Moreover, the system requires payor banks to upload customer account information to the central computer system. In addition to the fact that this requires a change in bank procedures, it also destroys the confidentiality of this information. Furthermore, as a result of the different time zones in the check clearing process and the fact that the system requires payor banks to upload their files, the information is never up-to date. In addition, the system does not describe how the point of sale terminal is updated with various sets of data, and cannot take into account various scenarios such as a course of action based on authorization results. Another disadvantage of this system is that it relies either on a continuous update of purchase and approval information into the negative/positive databases which are an input into the authorization process—in which case there is no suggestion on how the system should handle reversed transactions, or it settles transactions via the once-a-day ACH process—in which case there is a significant limitation in updating account status (and availability of funds) back into the central processing system.
It would be most desirable to provide a payment validation system that can support a wide variety of users, including merchants and banks. It would also be useful to have such a payment validation system that employs legacy systems, but in such a way as to maintain the confidentiality of proprietary information, such as banking information, which may be used to authorize a payment transaction. Furthermore, it is desirable to increase the accuracy of the validation in an economically efficient manner.